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=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 07B24C47096 for ; Thu, 3 Jun 2021 17:47:15 +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 D088E613E4 for ; Thu, 3 Jun 2021 17:47:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D088E613E4 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=bMnRyRO6cwBMQPQgrQ6Zw2S6/b8KdCvUzHMMSAUh4D0=; b=fapE3SQBn0cOJm /dFH27ExdjdU3sAV+sv8c4isGaN5jAntCBtorLMGbk2XJCVj+EC05XBZk6JHKLKO21ePl92U2THVj hSRQkGBr7Qn+o8ILqH0aK2z3pKJafn3yXlSXMHHj/kIelDu7qE3/oh19PXAJML35EAuSQ3v1Pd8xk 7wIWvJwVyyL1yzATYKdK3CP3ZC3KmhlDCbB7ymSc6g71aY/nQb0HvCA5FEJjc//oe8qCPlC/jbBEx W36HGsDCBUS6lbMCVhaVoS8EcOF8fXPXtYwPrOkSvruEwkxHlaCfenJ8iA2XtKxajHTB2K48Qb83O vgn8/qPiArDnOQLMQjZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lorPU-009x0e-7v; Thu, 03 Jun 2021 17:45:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lorPP-009wzD-EZ for linux-arm-kernel@lists.infradead.org; Thu, 03 Jun 2021 17:45:33 +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 6DCCD11B3; Thu, 3 Jun 2021 10:45:30 -0700 (PDT) Received: from bogus (unknown [10.57.73.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9C9CB3F73D; Thu, 3 Jun 2021 10:45:28 -0700 (PDT) Date: Thu, 3 Jun 2021 18:45:08 +0100 From: Sudeep Holla To: Florian Fainelli Cc: Etienne Carriere , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Cristian Marussi , Kevin Hilman , Neil Armstrong , Jerome Brunet , Jim Quinlan Subject: Re: [PATCH 2/2] firmware: arm_scmi: Add compatibility checks for shmem node Message-ID: <20210603174508.4t7l2tidmrtxlsft@bogus> References: <20210601225125.918225-1-sudeep.holla@arm.com> <20210601225125.918225-2-sudeep.holla@arm.com> <20210602073653.x4bon6jbiat2jnqv@bogus> <20210602075326.clypj7qmiv4gebas@bogus> <0963a5e1-5ce2-4ef4-7ff9-cbbea0f974d0@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210603_104531_625313_B035DFC8 X-CRM114-Status: GOOD ( 31.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, Jun 03, 2021 at 10:20:32AM -0700, Florian Fainelli wrote: > On 6/3/21 10:18 AM, Florian Fainelli wrote: > > On 6/2/21 12:53 AM, Sudeep Holla wrote: > >> On Wed, Jun 02, 2021 at 09:44:40AM +0200, Etienne Carriere wrote: > >>> On Wed, 2 Jun 2021 at 09:37, Sudeep Holla wrote: > >>>> > >>>> On Wed, Jun 02, 2021 at 09:33:03AM +0200, Etienne Carriere wrote: > >>>>> Hello Sudeep, > >>>>> > >>>>> > >>>>> On Wed, 2 Jun 2021 at 00:51, Sudeep Holla wrote: > >>>>>> > >>>>>> The shared memory node used for communication between the firmware and > >>>>>> the OS should be compatible with "arm,scmi-shmem". Add the check for the > >>>>>> same while parsing the node before fetching the memory regions. > >>>>>> > >>>>>> Cc: Cristian Marussi > >>>>>> Cc: Florian Fainelli > >>>>>> Cc: Jim Quinlan > >>>>>> Cc: Etienne Carriere > >>>>>> Signed-off-by: Sudeep Holla > >>>>>> --- > >>>>>> drivers/firmware/arm_scmi/mailbox.c | 3 +++ > >>>>>> drivers/firmware/arm_scmi/smc.c | 3 +++ > >>>>>> 2 files changed, 6 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c > >>>>>> index 4626404be541..e3dcb58314ae 100644 > >>>>>> --- a/drivers/firmware/arm_scmi/mailbox.c > >>>>>> +++ b/drivers/firmware/arm_scmi/mailbox.c > >>>>>> @@ -69,6 +69,9 @@ static int mailbox_chan_setup(struct scmi_chan_info *cinfo, struct device *dev, > >>>>>> return -ENOMEM; > >>>>>> > >>>>>> shmem = of_parse_phandle(cdev->of_node, "shmem", idx); > >>>>>> + if (!of_device_is_compatible(shmem, "arm,scmi-shmem")) > >>>>>> + return -ENXIO; > >>>>> > >>>>> Before this change, one could use another type of memory node, like "mmio-sram". > >>>>> Is there a strong reason to enforce use of "arm,scmi-shmem" nodes? > >>>>> > >>>> > >>>> No that is for the entire SRAM which still holds and generic on-chip SRAM > >>>> driver will take care of that, this is only for the subsections that is > >>>> reserved for the scp shmem. The binding has been always there, just the > >>>> missing check. When I move to yaml, I realised that and hence the > >>>> addition of check. > >>> > >>> Ok, I understand. True the binding was there but only in the DTS > >>> examples snipped. > >>> This constraint on the compatible property of the shmem node should be > >>> clearly stated in the yaml I think. > >>> > >> > >> Was this missing in your DTS files ? Just curious. > >> > > > > FWIW, our legacy DTs would have the following: > > > > reserved-memory { > > /* This is a placeholder */ > > NWMBOX: NWMBOX { > > }; > > }; > > > > brcm_scmi: brcm_scmi@0 { > > compatible = "arm,scmi-smc", "arm,scmi"; > > mboxes = <&brcm_scmi_mailbox 0>, <&brcm_scmi_mailbox 1>; > > mbox-names = "tx", "rx"; > > shmem = <&NWMBOX>; > > status = "disabled"; > > > > so while we have since switched to the SMC transport, the shared memory > > still does not have an "arm,scmi-shmem" compatible string, and this is a > > relatively new thing, so I am not sure we can enforce that just yet? > > Sorry, I incorrectly browsed the binding history, this is not a new > requirement, will make sure we fix it at our end, too. Indeed, I cross checked that when I hit the issue on Juno yesterday. Anyways this version has build issues, was sent by mistake. I have resend the correct ones later[1] -- Regards, Sudeep [1] https://lore.kernel.org/r/20210602073851.1005607-2-sudeep.holla@arm.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel