Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1920506imu; Wed, 12 Dec 2018 06:38:22 -0800 (PST) X-Google-Smtp-Source: AFSGD/XD3pDa4R538AZJAVTVXZZbgtHgxUvA3FDPlqwiQZLUvnFXOCdCC+byO4KB2eglts1mjPwc X-Received: by 2002:a63:4611:: with SMTP id t17mr18356289pga.119.1544625502762; Wed, 12 Dec 2018 06:38:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544625502; cv=none; d=google.com; s=arc-20160816; b=kEq4Iq2ZFhdkxGGqwQcLHG1mTnIeW1KXscC28ogmWboXvzOa2eIH52Lw7cmQuv0Ax3 NtXcOPs0KD5mt5Ri0b6+qP5hAiL/8kZyTx61rq50oM7YYpqa8F61O7s8szAzJhtKvcSA F1RhEcJAXqZqZK23be60ysIZqPgOi4+iUgyUIVkNMxOTNHS3QyuMnP+5/rlpjx9Cupmw 6rcupjIS/Jb8bLbKy4htyC201bwjCp1mCnEC9tLId/dLcbuzXDGwQVS+2YaMGXI27F8C kH2zH09HzK92TKPcVpK8BJEdIHSqhX2ER0iCRxQGeRSRTSr5xbvmumMHFb6pTAIE4wWb 6LrA== 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=zgAn7qGdM3ipbM9zznGf8Nz6Ez3nbwONrdJEFqslewU=; b=CuvsdpnF+6Eib66T8DJcE4g7Q6gtt9BgzBw8+M+LlAKgqz1kMI44c+Y3+PoojOvHFD m3VhT2hDIZJkp/Cu71utzMK9GicvTZBKjQZhpgGtXEdvMpqYj4Of3tD5BasU+hbf2Lr3 Z7KqyGMup65cK875RlpPSu28ohz69s+jJUe4tVYeGOrAAkVLhm8vAbbq0VkG7KHsWK+n hBlaZJgJRRiPO9ack2irGhqfQGj7qQo3B7re3vTmSGSwhip6MSIAtjmit+6j3C24bJ38 eJzBdBigPf/I8UhtUFS4H5+qoEa4Og+Qc3CoAjRFVWR2w+5v9ZsC5ol9h7v3Qx3DnEjO kVuQ== 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 b7si16114333plk.206.2018.12.12.06.38.07; Wed, 12 Dec 2018 06:38:22 -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 S1727505AbeLLOgG (ORCPT + 99 others); Wed, 12 Dec 2018 09:36:06 -0500 Received: from verein.lst.de ([213.95.11.211]:34364 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726232AbeLLOgG (ORCPT ); Wed, 12 Dec 2018 09:36:06 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id E5EB668D8D; Wed, 12 Dec 2018 15:36:04 +0100 (CET) Date: Wed, 12 Dec 2018 15:36:04 +0100 From: Christoph Hellwig To: Michael Ellerman Cc: Christoph Hellwig , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure Message-ID: <20181212143604.GA5137@lst.de> References: <20181114082314.8965-1-hch@lst.de> <20181114082314.8965-13-hch@lst.de> <871s6r3sno.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871s6r3sno.fsf@concordia.ellerman.id.au> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 09, 2018 at 09:23:39PM +1100, Michael Ellerman wrote: > Christoph Hellwig writes: > > > Configure the dma settings at device setup time, and stop playing games > > with get_pci_dma_ops. This prepares for using the common dma_configure > > code later on. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++--------- > > 1 file changed, 11 insertions(+), 9 deletions(-) > > This one's crashing, haven't dug into why yet: Can you provide a gdb assembly of the exact crash site? This looks like for some odd reason the DT structures aren't fully setup by the time we are probing the device, which seems odd. Either way, something like the patch below would ensure we call cell_iommu_get_fixed_address from a similar context as before, can you check if that fixes the issue? diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c index 93c7e4aef571..4891b338bf9f 100644 --- a/arch/powerpc/platforms/cell/iommu.c +++ b/arch/powerpc/platforms/cell/iommu.c @@ -569,19 +569,12 @@ static struct iommu_table *cell_get_iommu_table(struct device *dev) return &window->table; } -static u64 cell_iommu_get_fixed_address(struct device *dev); - static void cell_dma_dev_setup(struct device *dev) { - if (cell_iommu_enabled) { - u64 addr = cell_iommu_get_fixed_address(dev); - - if (addr != OF_BAD_ADDR) - set_dma_offset(dev, addr + dma_iommu_fixed_base); + if (cell_iommu_enabled) set_iommu_table_base(dev, cell_get_iommu_table(dev)); - } else { + else set_dma_offset(dev, cell_dma_nommu_offset); - } } static void cell_pci_dma_dev_setup(struct pci_dev *dev) @@ -865,8 +858,16 @@ static u64 cell_iommu_get_fixed_address(struct device *dev) static bool cell_pci_iommu_bypass_supported(struct pci_dev *pdev, u64 mask) { - return mask == DMA_BIT_MASK(64) && - cell_iommu_get_fixed_address(&pdev->dev) != OF_BAD_ADDR; + if (mask == DMA_BIT_MASK(64)) { + u64 addr = cell_iommu_get_fixed_address(&pdev->dev); + + if (addr != OF_BAD_ADDR) { + set_dma_offset(&pdev->dev, dma_iommu_fixed_base + addr); + return true; + } + } + + return true; } static void insert_16M_pte(unsigned long addr, unsigned long *ptab,