Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp267426imm; Tue, 25 Sep 2018 21:21:01 -0700 (PDT) X-Google-Smtp-Source: ACcGV60qtu996Use0eJotCS8zjsp6RPVyNdG/Vjf5ZA1mzWFpY4FmIuc5mLqKixGMeIHESztByOQ X-Received: by 2002:a63:2c01:: with SMTP id s1-v6mr3707849pgs.367.1537935661552; Tue, 25 Sep 2018 21:21:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537935661; cv=none; d=google.com; s=arc-20160816; b=hjGDseP8TocC6DwireqDCItJwNEqcoTg2OaqLfaDZzBIHLWwYZZT4K9dQA7gO0EU0r on4GFxhwjiTLNHv1mmP9LBXOidPOIGzzePsT3QmdtojvDgTOrDx5/e/ibv/4syseopJs apC5RoYyvMcACDypI4LSkoCwsZKJBh8tU5AvgqwzqTiO3951crFZhPwL5zig4xAIkCSA Fs3M5djfZfxNlDxsF1quG8DwfcrrVSqW8q0IA5CRB16v09vcorTlFBVX7UGkst9hHVho +1MGufKNOK/1HzNWq5g/s7xQumtDgYrNd3rSWZMEt6gOe1h/1FR1/wNdAKc4drY98hdV CRYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=s8BVVa/ERF9ShaA680hG0l+CdI2+negn61mnxfxmH0I=; b=DSMUvFn7+3quyc+DvavBTScj4NMeIPmFDV+KMYPxkI6CYXOJNjyUQiowJPLOima6yH hZozFkXRrHtKbn+WKKfd8Dq6Ax32yPKr3Anohp+uULhvfo/yOkzpta+5r7IXMPPBH7u+ KQMaw0r8wrb3egykb+H6sY8emXRWRfg/dJXJjryV9LcGrgRxh8FeBqPXMZMkFZooZjQg xLnxYfSkGAYypOKiQoBDIiPPuphNiHkajlbETZEjDUlUBJrYVWkqh4CfIbRREE5ScOBG FaZlPkWsx1BdkPt+l9oTXNo99qaHRxIe7pm/VFpEuKDdEKjHdI/l5xlgNj0pEZFPg3cU M9Og== 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 g10-v6si1465567plt.212.2018.09.25.21.20.44; Tue, 25 Sep 2018 21:21:01 -0700 (PDT) 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 S1726591AbeIZKbX (ORCPT + 99 others); Wed, 26 Sep 2018 06:31:23 -0400 Received: from ozlabs.org ([203.11.71.1]:41605 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726175AbeIZKbX (ORCPT ); Wed, 26 Sep 2018 06:31:23 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 42Kl920wH1z9s4s; Wed, 26 Sep 2018 14:20:22 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Christoph Hellwig , Guenter Roeck Cc: Christoph Hellwig , iommu@lists.linux-foundation.org, Greg Kroah-Hartman , Robin Murphy , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Marek Szyprowski , Bjorn Helgaas , linux-pci@vger.kernel.org, Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 4/4] dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops In-Reply-To: <20180925201619.GB8413@lst.de> References: <20180827084711.23407-1-hch@lst.de> <20180827084711.23407-5-hch@lst.de> <20180922150119.GA14761@roeck-us.net> <20180925201619.GB8413@lst.de> Date: Wed, 26 Sep 2018 14:20:19 +1000 Message-ID: <87r2hgga9o.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Hellwig writes: > Looking at the code I think this commit is simply broken for > architectures not using arch_setup_dma_ops, but instead setting up > the dma ops through arch specific magic. I arch_setup_dma_ops() called from of_dma_configure(), but pci_dma_configure() doesn't call that for this device: static int pci_dma_configure(struct device *dev) { ... if (IS_ENABLED(CONFIG_OF) && bridge->parent && bridge->parent->of_node) { ret = of_dma_configure(dev, bridge->parent->of_node, true); bridge->parent is NULL. So I don't think arch_setup_dma_ops() would help here? > I'll revert the patch. Thanks. cheers