Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp7467809ybn; Mon, 30 Sep 2019 14:27:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJk84z61X2suhHvZ0aPf/WDE9R9nWrVk4v4Vrc4mDuYGoObKdiMUO49kW9zpUddkwpoh0x X-Received: by 2002:a17:906:349a:: with SMTP id g26mr20556983ejb.77.1569878873463; Mon, 30 Sep 2019 14:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569878873; cv=none; d=google.com; s=arc-20160816; b=PEDH7u9v1ApEq3uEpKV0iAaQPkqDwewPcTQ7lIH5SBJEhSuqRQ2BfCURw8E2HvL+qO ZZ0hK0Pn6OMYRzKMsHxiAGlZPKyxHxbsAL8wGXfTiZiRC++Yqjzem06mVn3950dYb34h SAZQoeW9MsBMnddADeOQiPAwPG1hPR9Sk3xPgCeIqWPb5cN3RkMvDh2mOsuonQZNJh5Z 3AO1P/8bqtknkYiCQXxJ4Oy6ezmTOWtoAXjtn4fNSz6+bqsoH0EQqZfLFZMGHiG8Zow2 RKJfLIUgEJ1QlW+4ZzLotkHwSzgeNlw5W85xun0+620ffSPCaCmLXhoFo4LBb6bcV9Rr MJ8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=BfNvjIfr5bdeBrF/unhzqe0ESoPL2JAjA5TuSVqY59c=; b=hNwlVc9ME+odO1SkH8ZjiaGPNvnAYnVvEyIpsRsXzCtmBmwk6xBXl2Per0IRoBxOq3 NgdHWf3AYpU6sM0GXU2dbSdRUTDvyQ4gYhG1x7b+jbWbOUOPkI9QAXTFA1T7QPKuVAoT BLmSdmwZEotjeGuxCMSMV4S0DFYqnE2+Sflm4SzBDWmMGReFyQZIFUB6SYn/UCdEBU6k lmBQOOO2+hdSzuYYDfHTELaA778mIHdALnPwM46jWM/aUXSCFtNgJBcWxROkvbpxNS21 gmyqxZV+t0LwSklFh2HxjAu5IGuZXJz4BfPTi2scVSkduCxio1XVnTeTHdUKHiKu0O4b AoKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=XbxRSBb5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c24si7786478edt.364.2019.09.30.14.27.28; Mon, 30 Sep 2019 14:27:53 -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; dkim=pass header.i=@kernel.org header.s=default header.b=XbxRSBb5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732553AbfI3VYe (ORCPT + 99 others); Mon, 30 Sep 2019 17:24:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:49302 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727469AbfI3VYe (ORCPT ); Mon, 30 Sep 2019 17:24:34 -0400 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 690E721920; Mon, 30 Sep 2019 21:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569878672; bh=O0YTj2vhvn3cLJ9bXhjvMPrKFz9pub2mp+NyxMOgLgY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XbxRSBb5GzUwqvHLEh5933b2ncHabYYcy1H+PGoWAURC6L6OdvUSkMXSuI0Iao+qZ 0/XMhv/X8S8fJpHTkfs7dgHQrJiQtHY7DLVpLSN5KbV0sqXQhr4XPG2Cj2rZnridY7 w1jj9r+Rs3EGC9eEA/lZ15W3yzaU9R0022RF1Dto= Received: by mail-qt1-f177.google.com with SMTP id 3so18976777qta.1; Mon, 30 Sep 2019 14:24:32 -0700 (PDT) X-Gm-Message-State: APjAAAXAshFanHEZgU5iZwlV8eAxuby5/lsuknWOk8eiTQuBJlikpRMh vdfvLeuBnE+lnknRZiRQaqqByPZDb6CuLwWPoQ== X-Received: by 2002:ac8:31b3:: with SMTP id h48mr28091603qte.300.1569878671519; Mon, 30 Sep 2019 14:24:31 -0700 (PDT) MIME-Version: 1.0 References: <20190927002455.13169-1-robh@kernel.org> <20190927002455.13169-6-robh@kernel.org> <20190930125752.GD12051@infradead.org> <95f8dabea99f104336491281b88c04b58d462258.camel@suse.de> In-Reply-To: <95f8dabea99f104336491281b88c04b58d462258.camel@suse.de> From: Rob Herring Date: Mon, 30 Sep 2019 16:24:20 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/11] of: Ratify of_dma_configure() interface To: Nicolas Saenz Julienne Cc: Christoph Hellwig , devicetree@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Florian Fainelli , Arnd Bergmann , Frank Rowand , PCI , "linux-kernel@vger.kernel.org" , Marek Vasut , Lorenzo Pieralisi , Oza Pawandeep , Stefan Wahren , Simon Horman , Geert Uytterhoeven , Robin Murphy Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 30, 2019 at 8:32 AM Nicolas Saenz Julienne wrote: > > On Mon, 2019-09-30 at 05:57 -0700, Christoph Hellwig wrote: > > On Thu, Sep 26, 2019 at 07:24:49PM -0500, Rob Herring wrote: > > > -int of_dma_configure(struct device *dev, struct device_node *np, bool > > > force_dma) > > > +int of_dma_configure(struct device *dev, struct device_node *parent, bool > > > force_dma) > > > > This creates a > 80 char line. > > > > > { > > > u64 dma_addr, paddr, size = 0; > > > int ret; > > > bool coherent; > > > unsigned long offset; > > > const struct iommu_ops *iommu; > > > + struct device_node *np; > > > u64 mask; > > > > > > + np = dev->of_node; > > > + if (!np) > > > + np = parent; > > > + if (!np) > > > + return -ENODEV; > > > > I have to say I find the older calling convention simpler to understand. > > If we want to enforce the invariant I'd rather do that explicitly: > > > > if (dev->of_node && np != dev->of_node) > > return -EINVAL; > > As is, this would break Freescale Layerscape fsl-mc bus' dma_configure(): This may break PCI too for devices that have a DT node. > static int fsl_mc_dma_configure(struct device *dev) > { > struct device *dma_dev = dev; > > while (dev_is_fsl_mc(dma_dev)) > dma_dev = dma_dev->parent; > > return of_dma_configure(dev, dma_dev->of_node, 0); > } > > But I think that with this series, given the fact that we now treat the lack of > dma-ranges as a 1:1 mapping instead of an error, we could rewrite the function > like this: Now, I'm reconsidering allowing this abuse... It's better if the code which understands the bus structure in DT for a specific bus passes in the right thing. Maybe I should go back to Robin's version (below). OTOH, the existing assumption that 'dma-ranges' was in the immediate parent was an assumption on the bus structure which maybe doesn't always apply. diff --git a/drivers/of/device.c b/drivers/of/device.c index a45261e21144..6951450bb8f3 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -98,12 +98,15 @@ int of_dma_configure(struct device *dev, struct device_node *parent, bool force_ u64 mask; np = dev->of_node; - if (!np) - np = parent; + if (np) + parent = of_get_dma_parent(np); + else + np = of_node_get(parent); if (!np) return -ENODEV; - ret = of_dma_get_range(np, &dma_addr, &paddr, &size); + ret = of_dma_get_range(parent, &dma_addr, &paddr, &size); + of_node_put(parent); if (ret < 0) { /* * For legacy reasons, we have to assume some devices need