Received: by 10.213.65.68 with SMTP id h4csp536232imn; Tue, 13 Mar 2018 12:12:01 -0700 (PDT) X-Google-Smtp-Source: AG47ELv6RK9pm8d8Bt+UMsDvJEE47Jb9xc3Epa0dWFdo0OrL6ux4Gp4ZfpGKgrChX7PCdoXADdHd X-Received: by 10.99.186.72 with SMTP id l8mr891676pgu.410.1520968320996; Tue, 13 Mar 2018 12:12:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520968320; cv=none; d=google.com; s=arc-20160816; b=E0O+4nYLyrQ9d5SnWXGOaXqCfnTor+qKcks4izBXbtuI92w2n6zIABdn1p4xVcFdqo X9+8htQF7QTj0jmHQcPRFX/gF3NcWCwKq7Gtw2LV6OnWFVOfHkSUEfyu5rZ8mEP+gm2t YEJ/F47VoDgvQjweybtCNCpvYWGHkc6rW7Z8qqnpSdvjZZ7c2SH+JxKQaVy0+4Lr/dDP gen6tJVsrG2w5yy3v7Ae4UTkwbkHNmSDiAy/r9hlJ1yDuK2W5ndePGKDObKAUf4F8yjI F65BTAf4aQb62/n9kApGuU/PukgEUnj+ZxnQ7nLP/A95LLXO7JW0pdMHeM1Qsu7xNBGo aFgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=lFwQPlh42Q2o6Y4+yrgRtLaimkJpVbUg0F7vAjhgHi4=; b=dudu9OsmwtdOpHdbxeRSGp4pqp8J/2BF8in70+cOrZZvFdmDnohZnj7RH1NP+PirXW AV9o5IaekF+6KkIEu9+Y1ZMMEL7wZ1ywMzHRDjxT/h9LqNIWR8qTZPqE8vL8aPDSGvsN N0YCgCIIOx3xZDOAkabdO58svz+//5DA//9vSDYSQn0zX9bkJU0yKV5FYDAwdPEntqUa MAckqbYqLYwDtuMcKxxcXeL+zGJtlGqLVn7K4RqfWvqXTRR040OPfCYDMp1IcwKg6bkq wticoEyE7Yj5TtUdH9RG1LgQnbCQ3j6lp5eHUEdyv5wYJ5OELqAsqjAnVSZfKiRABkM3 9fVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=S4ZefpAb; dkim=pass header.i=@codeaurora.org header.s=default header.b=S4ZefpAb; 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 a68si192010pgc.467.2018.03.13.12.11.46; Tue, 13 Mar 2018 12:12:00 -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=@codeaurora.org header.s=default header.b=S4ZefpAb; dkim=pass header.i=@codeaurora.org header.s=default header.b=S4ZefpAb; 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 S1752189AbeCMTKy (ORCPT + 99 others); Tue, 13 Mar 2018 15:10:54 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:56548 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751901AbeCMTKw (ORCPT ); Tue, 13 Mar 2018 15:10:52 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E8D8C60851; Tue, 13 Mar 2018 19:10:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520968251; bh=3FACyZVwaRypSeoHeHPVztukdKDIQXWIDO6+zkzmlm4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S4ZefpAbm8ATD8vIPT6NuVyHSChffkNiP6DPdKnoVuZGBmzOzsczLi1JiW0IEYcz1 1XqySMERy69tZAkIsHaWo2urOeT8jKJKw1FglCUyKI8i/na4odRS3VFJajkEMSx0wq Rjz+z3nlwhcwnfKLfN2eiSNp+uj0G1ma0CHWztGc= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.235.228.150] (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 492BD60592; Tue, 13 Mar 2018 19:10:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520968251; bh=3FACyZVwaRypSeoHeHPVztukdKDIQXWIDO6+zkzmlm4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S4ZefpAbm8ATD8vIPT6NuVyHSChffkNiP6DPdKnoVuZGBmzOzsczLi1JiW0IEYcz1 1XqySMERy69tZAkIsHaWo2urOeT8jKJKw1FglCUyKI8i/na4odRS3VFJajkEMSx0wq Rjz+z3nlwhcwnfKLfN2eiSNp+uj0G1ma0CHWztGc= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 492BD60592 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory To: Logan Gunthorpe , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, linux-block@vger.kernel.org Cc: Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson References: <20180312193525.2855-1-logang@deltatee.com> <20180312193525.2855-2-logang@deltatee.com> <59fd2f5d-177f-334a-a9c4-0f8a6ec7c303@codeaurora.org> <24d8e5c2-065d-8bde-3f5d-7f158be9c578@deltatee.com> <52cbbbc4-c488-f83f-8d02-14d455b4efd7@codeaurora.org> <3e738f95-d73c-4182-2fa1-8664aafb1ab7@deltatee.com> From: Sinan Kaya Message-ID: <703aa92c-0c1c-4852-5887-6f6e6ccde0fb@codeaurora.org> Date: Tue, 13 Mar 2018 15:10:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3e738f95-d73c-4182-2fa1-8664aafb1ab7@deltatee.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/13/2018 2:44 PM, Logan Gunthorpe wrote: >> Do you think you can keep a pointer to the parent bridge instead of querying it >> via get_upstream_bridge_port() here so that we can reuse your >> pci_p2pdma_disable_acs() in the future. > > Keep a pointer where? pci_p2pdma_disable_acs() and pci_p2pdma_add_client() are used in completely different cases on completely different devices. There really is no overlap and no obvious place to store the port pointer (except in the struct pci_dev itself, in which case why not just call the function again). I was thinking of this for the pci_p2pdma_add_client() case for the parent pointer. +struct pci_p2pdma_client { + struct list_head list; + struct pci_dev *client; + struct pci_dev *provider; +}; You are right second code seems to be there to disable ACS altogether when this kernel configuration is selected. It doesn't have any relationship to the client code. But then, Why bother searching for the switch at all? Even if the switch is there, there is no guarantee that it is currently being used for P2P. It seems that we are going with the assumption that enabling this config option implies you want P2P, then we can simplify this code as well. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.