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=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 BF25DC11F69 for ; Fri, 2 Jul 2021 13:18:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9A0961413 for ; Fri, 2 Jul 2021 13:18:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232583AbhGBNVN (ORCPT ); Fri, 2 Jul 2021 09:21:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:44320 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232363AbhGBNVM (ORCPT ); Fri, 2 Jul 2021 09:21:12 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4D3B36109D; Fri, 2 Jul 2021 13:18:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625231920; bh=GDNc99vWU2EKYVywroGm/MONGRMfJ1bw5GtcP1Kxyew=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UpJXnxcF4r+u8N9In3Ngt/3KsBiIssEtR46hbKVGD4imJoDwZps2CiNu9/tX6XODL RkRPeCMJzkowmvGyx+vBIS2hY1z4ccknZBrbZdUt3JmjE2xh4ItTea2grkiScPUhIn HLmoRTEOJQbfW+p5GY0xQ0VKUewGU1RsIqEJOhMbpuv3pp74w18YlrSAOnrKBIP55s v+J/uIyo0HZY5XHsn1OOtuplTl/3fBAHP0aXr8wAQJjJJZ7gIcW+IXijJkOA5vhe1e A78+z8Z0KIiDl7b4jtkq2bGKSaVHIDksVIMFkEDwiE3IncWj68Vxm0ezE9lm9A76mg Qcdpn8Gt/MWYA== Date: Fri, 2 Jul 2021 14:18:29 +0100 From: Will Deacon To: Robin Murphy Cc: Guenter Roeck , Claire Chang , Rob Herring , mpe@ellerman.id.au, Joerg Roedel , Frank Rowand , Konrad Rzeszutek Wilk , boris.ostrovsky@oracle.com, jgross@suse.com, Christoph Hellwig , Marek Szyprowski , heikki.krogerus@linux.intel.com, thomas.hellstrom@linux.intel.com, peterz@infradead.org, dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org, mingo@kernel.org, jxgao@google.com, sstabellini@kernel.org, Saravana Kannan , xypron.glpk@gmx.de, "Rafael J . Wysocki" , Bartosz Golaszewski , bskeggs@redhat.com, linux-pci@vger.kernel.org, xen-devel@lists.xenproject.org, Thierry Reding , intel-gfx@lists.freedesktop.org, matthew.auld@intel.com, linux-devicetree , airlied@linux.ie, Nicolas Boichat , rodrigo.vivi@intel.com, bhelgaas@google.com, Dan Williams , Andy Shevchenko , Greg KH , Randy Dunlap , quic_qiancai@quicinc.com, lkml , tfiga@chromium.org, "list@263.net:IOMMU DRIVERS" , Jim Quinlan , thomas.lendacky@amd.com, linuxppc-dev@lists.ozlabs.org, bauerman@linux.ibm.com Subject: Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool Message-ID: <20210702131829.GA11132@willie-the-truck> References: <20210624155526.2775863-1-tientzu@chromium.org> <20210624155526.2775863-13-tientzu@chromium.org> <20210702030807.GA2685166@roeck-us.net> <87ca3ada-22ed-f40c-0089-ca6fffc04f24@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ca3ada-22ed-f40c-0089-ca6fffc04f24@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote: > On 2021-07-02 04:08, Guenter Roeck wrote: > > On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote: > > > If a device is not behind an IOMMU, we look up the device node and set > > > up the restricted DMA when the restricted-dma-pool is presented. > > > > > > Signed-off-by: Claire Chang > > > Tested-by: Stefano Stabellini > > > Tested-by: Will Deacon > > > > With this patch in place, all sparc and sparc64 qemu emulations > > fail to boot. Symptom is that the root file system is not found. > > Reverting this patch fixes the problem. Bisect log is attached. > > Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably > returning an unexpected -ENODEV from the of_dma_set_restricted_buffer() > stub. That should probably be returning 0 instead, since either way it's not > an error condition for it to simply do nothing. Something like below? Will --->8 >From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Fri, 2 Jul 2021 14:13:28 +0100 Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when !OF_ADDRESS When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV and breaks the boot for sparc[64] machines. Return 0 instead, since the function is essentially a glorified NOP in this configuration. Cc: Claire Chang Cc: Konrad Rzeszutek Wilk Reported-by: Guenter Roeck Suggested-by: Robin Murphy Link: https://lore.kernel.org/r/20210702030807.GA2685166@roeck-us.net Signed-off-by: Will Deacon --- drivers/of/of_private.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h index 8fde97565d11..34dd548c5eac 100644 --- a/drivers/of/of_private.h +++ b/drivers/of/of_private.h @@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np, static inline int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np) { - return -ENODEV; + /* Do nothing, successfully. */ + return 0; } #endif -- 2.32.0.93.g670b81a890-goog