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=-1.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E3FE4C49ED7 for ; Wed, 11 Sep 2019 02:36:56 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id B40AB2171F for ; Wed, 11 Sep 2019 02:36:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YcYqJJ9M"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bSkmHAeU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B40AB2171F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.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=TpZ24DuGBmACQu6IM9xxbACHNtuds4z/CLzxNEJeQgM=; b=YcYqJJ9MhO9T3t BXAAs9W8ywVrIKWZw5wlulj0tDJeLDN26Dk3M7B0Lq68xOenqdOatce5Eptt4p6RbFEnUcyBejcG1 uFWmBLm6PxdSAM7vI1g6EkWA9BUz9asntxNB4ER3xl+w726sSpn8P17ZhHu2VlgmO5iBmZlwWxhcE fJZds2cCYrMyRHG5XwR43kwtZJ2Pffoyni4mUJw8pDSg4k9ANeHDGxb1nNV0xqU1bvbErk82kKIEy HpguAGtVb1PyHnvoRvtzcKAP7SlnS+vD8w0KDUVG0aRkMotjT/28Y5nWH48ZMT5+SCpP/FtdGnuM6 p/9YwJUx3yXAr1ChEdOw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i7sV0-0002nj-UT; Wed, 11 Sep 2019 02:36:50 +0000 Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i7sUx-0002n2-ME for linux-arm-kernel@lists.infradead.org; Wed, 11 Sep 2019 02:36:49 +0000 Received: by mail-io1-xd41.google.com with SMTP id m11so42406350ioo.0 for ; Tue, 10 Sep 2019 19:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OwUw/A+EuWCuR5fA3FXok+c2wlYUpc7vdIubwfDS7IA=; b=bSkmHAeUBk6i8XFvgk1v0d1YocIoUrBFVfhPqlhu3N4fOjDvoD9EKa5F7KTsgSREs2 o5xzdhi6N4aiRN9s4Q0hBRGZflMQutIV+HiSEwfjTg2AiQOLAdhAs1kI4An2ef3WCNVL aXK56vdC4ezdwGGkjS3YSc+HNWAGPyYd/9Ok1CJwvAR/9Q+cUUT8x1hGlC/dGojKguBw z0TcOLN8zfDnbs89SyXBu4UAJdL/OwgajnmSsah4twlbSlnf+m2zN8PT5zm+aA0bz1gj CJcwOIE3nP1fYa+Fe3Ci3Wyjj0kA0IkcVZMyHWvJE+2rBWhXsFMAbP73H7eIf/V+/JR2 CIkg== 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=OwUw/A+EuWCuR5fA3FXok+c2wlYUpc7vdIubwfDS7IA=; b=QZYQ2h/jPYo+vd51U2lCa+mRcxQN9HnGkdIdVvUwidOl7RG/iorJbb1+NSb3CaXmrV DpGB2LaDJN1vmrw+FYoFyYxDfPJy4GBKOWrwNTfJdl3P2ifGphHHNMNxpW5OJKTmwDx0 0lotMDy9VE57l9pY2sgUxGTPMg/VUMokfnaQ/VrtaGWYwxivov4BVnMfDxomp0RD+N37 1YWaSBA6bfyOMwZYqyQy7vPRu1elV6ztJ6cZlPriGtYaGB94NdH01CJpqc9R2NtbzBEe LNyRv+xD0xfihRYlIr5xIf+EDpdgHLDUlB29MHRyBQb8YiUaCUv+I22WXIdl6/rA9T4z BWZA== X-Gm-Message-State: APjAAAVsIXkh7ZZb4vTmtZih5xE0VrI2imsxV/lW/pw8wD9exb/RhkRq EKe18sEmWZU/6bpbJSAiA3IjcJ4Y3lfGvIEDLiY= X-Google-Smtp-Source: APXvYqyJ8ndRsk4DRRqFvjYNPP3fbctVHqsRkMdlHOlE1KyA4ZrDzKhq+wPo3x4T57rpNyZnntrLcrIIBHq6s2fubcY= X-Received: by 2002:a6b:e609:: with SMTP id g9mr13267243ioh.7.1568169406511; Tue, 10 Sep 2019 19:36:46 -0700 (PDT) MIME-Version: 1.0 References: <1567004515-3567-1-git-send-email-peng.fan@nxp.com> <1567004515-3567-2-git-send-email-peng.fan@nxp.com> <20190909143230.48b1143f@donnerap.cambridge.arm.com> In-Reply-To: <20190909143230.48b1143f@donnerap.cambridge.arm.com> From: Jassi Brar Date: Tue, 10 Sep 2019 21:36:35 -0500 Message-ID: Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox To: Andre Przywara X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190910_193647_750164_FF3D98AE X-CRM114-Status: GOOD ( 21.53 ) 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: "mark.rutland@arm.com" , "devicetree@vger.kernel.org" , Peng Fan , "f.fainelli@gmail.com" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , dl-linux-imx , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Sep 9, 2019 at 8:32 AM Andre Przywara wrote: > > On Fri, 30 Aug 2019 03:12:29 -0500 > Jassi Brar wrote: > > Hi, > > > On Fri, Aug 30, 2019 at 3:07 AM Peng Fan wrote: > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > > > > SMC/HVC mailbox > > > > > > > > On Fri, Aug 30, 2019 at 2:37 AM Peng Fan wrote: > > > > > > > > > > Hi Jassi, > > > > > > > > > > > Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc > > > > > > for the ARM SMC/HVC mailbox > > > > > > > > > > > > On Fri, Aug 30, 2019 at 1:28 AM Peng Fan wrote: > > > > > > > > > > > > > > > +examples: > > > > > > > > > + - | > > > > > > > > > + sram@910000 { > > > > > > > > > + compatible = "mmio-sram"; > > > > > > > > > + reg = <0x0 0x93f000 0x0 0x1000>; > > > > > > > > > + #address-cells = <1>; > > > > > > > > > + #size-cells = <1>; > > > > > > > > > + ranges = <0 0x0 0x93f000 0x1000>; > > > > > > > > > + > > > > > > > > > + cpu_scp_lpri: scp-shmem@0 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x0 0x200>; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + cpu_scp_hpri: scp-shmem@200 { > > > > > > > > > + compatible = "arm,scmi-shmem"; > > > > > > > > > + reg = <0x200 0x200>; > > > > > > > > > + }; > > > > > > > > > + }; > > > > > > > > > + > > > > > > > > > + firmware { > > > > > > > > > + smc_mbox: mailbox { > > > > > > > > > + #mbox-cells = <1>; > > > > > > > > > + compatible = "arm,smc-mbox"; > > > > > > > > > + method = "smc"; > > > > > > > > > + arm,num-chans = <0x2>; > > > > > > > > > + transports = "mem"; > > > > > > > > > + /* Optional */ > > > > > > > > > + arm,func-ids = <0xc20000fe>, <0xc20000ff>; > > > > > > > > > > > > > > > > > SMC/HVC is synchronously(block) running in "secure mode", i.e, > > > > > > > > there can only be one instance running platform wide. Right? > > > > > > > > > > > > > > I think there could be channel for TEE, and channel for Linux. > > > > > > > For virtualization case, there could be dedicated channel for each VM. > > > > > > > > > > > > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't > > > > > > both be active at the same time, right? > > > > > > > > > > If I get your point correctly, > > > > > On UP, both could not be active. On SMP, tx/rx could be both active, > > > > > anyway this depends on secure firmware and Linux firmware design. > > > > > > > > > > Do you have any suggestions about arm,func-ids here? > > > > > > > > > I was thinking if this is just an instruction, why can't each channel be > > > > represented as a controller, i.e, have exactly one func-id per controller node. > > > > Define as many controllers as you need channels ? > > > > > > I am ok, this could make driver code simpler. Something as below? > > > > > > smc_tx_mbox: tx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000fe>; > > > }; > > > > > > smc_rx_mbox: rx_mbox { > > > #mbox-cells = <0>; > > > compatible = "arm,smc-mbox"; > > > method = "smc"; > > > transports = "mem"; > > > arm,func-id = <0xc20000ff>; > > > }; > > > > > > firmware { > > > scmi { > > > compatible = "arm,scmi"; > > > mboxes = <&smc_tx_mbox>, <&smc_rx_mbox 1>; > > > mbox-names = "tx", "rx"; > > > shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; > > > }; > > > }; > > > > > Yes, the channel part is good. > > But I am not convinced by the need to have SCMI specific "transport" mode. > > Why would this be SCMI specific and what is the problem with having this property? > By the very nature of the SMC/HVC call you would expect to also pass parameters in registers. > However this limits the amount of data you can push, so the option of reverting to a > memory based payload sounds very reasonable. > Of course, it is very legit to pass data via mem and many platforms do that. But as you note in your next post, the 'transport' doesn't seem necessary doing what it does in the driver. Cheers! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel