Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp642205ybl; Fri, 10 Jan 2020 04:28:36 -0800 (PST) X-Google-Smtp-Source: APXvYqzSnP6ZCJqRkl6UDiPwV7jqAec3bCgxq+OxFr9CVHWcm00dyCy5SoQIZg/QRIWo5/iOr7BU X-Received: by 2002:aca:490e:: with SMTP id w14mr1976424oia.67.1578659316600; Fri, 10 Jan 2020 04:28:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578659316; cv=none; d=google.com; s=arc-20160816; b=UyvJf9hBGqIDYrL6a+Ut/p2mFfJ2WleqsZfJeddb7KrK6iHuCvWVzos3B1JWKDz0ly 6dUtGhDSzX5nQpvNSBMkKefptaTM6Rr8ZtbgJQDdCge4OfFM+pZKLlge2L+8sp+duXmV 2A9l9eSKhQ2aNnzUIgEBt0+m+UjeYHyQ17ohCzZ21HmHfaMn4HvxFijniv/i8axnINcY QWOR4dQGI9V5kdyppTQE91pRAnbaLhg/0w+Y/Gi1P0L1RBwxjCWoBy0CdtfzRCT1MlF3 Vz39iLF7aDqrEmipPo7F2YwMg0lubqCqln8slTe0kCNgEkd9BpG+zwtf2EpcjXO95bij OYhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=oKmg5KnXXZ1EMJt9S658SKjpqKVgsUNRmDsQoVLVWDE=; b=Cvii5iYNxc3MyQ1EkW5B3Ilz3wNa6Z7W5gOnSFSvI+LFBfCuT6TnERxUkn1bbQZBzs ToRu8xuFuRm5756u/7Q6jls2zluvAHPNX8bnavRWFdy4FIkrPlMa2cnIFWTkbJpx2k2d bXmrBRB7wP/3hOEE+1bBwoLRG8mAz51QUcnYDxVw6oexQSWXpIlJ7ruP48RdybWD+bd/ RjHD14qpQGrGIKzyejUUdDpBSwyol+V6gUBeI+hXuio9IlDsWGZH9M7M/MRf+wp2fbiD wRSBoKbC1BA815Kpr8ZhakPGCCR3YEanoB9fcUz/M4dl9VlQj1otaAr4hugs3IgisWar 2F6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t142si972076oih.242.2020.01.10.04.28.25; Fri, 10 Jan 2020 04:28:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728010AbgAJM1a (ORCPT + 99 others); Fri, 10 Jan 2020 07:27:30 -0500 Received: from foss.arm.com ([217.140.110.172]:43886 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727753AbgAJM13 (ORCPT ); Fri, 10 Jan 2020 07:27:29 -0500 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 0C9B01063; Fri, 10 Jan 2020 04:27:29 -0800 (PST) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E69F33F534; Fri, 10 Jan 2020 04:27:27 -0800 (PST) Date: Fri, 10 Jan 2020 12:27:25 +0000 From: Sudeep Holla To: Viresh Kumar Cc: Arnd Bergmann , peng.fan@nxp.com, Vincent Guittot , Jassi Brar , "linux-kernel@vger.kernel.org" , Sudeep Holla , Linux ARM Subject: Re: [PATCH] firmware: arm_scmi: Make scmi core independent of transport type Message-ID: <20200110122725.GB45077@bogus> References: <5c545c2866ba075ddb44907940a1dae1d823b8a1.1575019719.git.viresh.kumar@linaro.org> <20200109093442.4jt44eu2zlmjaq3f@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200109093442.4jt44eu2zlmjaq3f@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 09, 2020 at 03:04:42PM +0530, Viresh Kumar wrote: > On 09-01-20, 09:18, Arnd Bergmann wrote: > > On Fri, Nov 29, 2019 at 10:32 AM Viresh Kumar wrote: > > > > > > The SCMI specification is fairly independent of the transport protocol, > > > which can be a simple mailbox (already implemented) or anything else. > > > The current Linux implementation however is very much dependent of the > > > mailbox transport layer. > > > > > > This patch makes the SCMI core code (driver.c) independent of the > > > mailbox transport layer and moves all mailbox related code to a new > > > file: mailbox.c. > > > > > > We can now implement more transport protocols to transport SCMI > > > messages. > > > > > > The transport protocols just need to provide struct scmi_transport_ops, > > > with its version of the callbacks to enable exchange of SCMI messages. > > > > > > Signed-off-by: Viresh Kumar > > > > Conceptually I think this is fine, but as others have said, it would be > > better to have another transport implementation posted along with this > > to see if the interfaces actually work out. > > @Sudeep/Vincent: Do you think we can add another transport > implementation something right away for it ? > Even if we don't add new transport right away, I would like to see if the requirements are met. I will take a look at you v2 with that in mind anyways. We need not wait, we I want to see people think it meets their requirement. I will also add couple of guys working on virtio transport for SCMI when I respond to your v2. Thanks for posting it. > @Peng ? > Peng, Did you get a chance to try this with SMC ? If SCMI was the only usecase, you can try this approach instead of mailbox, now that no one has any objects to this approach conceptually. Please use v2 as base and update us. -- Regards, Sudeep