From patchwork Fri Mar 24 16:16:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 743267 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3vqT8P6YvWz9s0m for ; Sat, 25 Mar 2017 03:17:09 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="bJc32lkA"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966291AbdCXQQ5 (ORCPT ); Fri, 24 Mar 2017 12:16:57 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:36680 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966285AbdCXQQu (ORCPT ); Fri, 24 Mar 2017 12:16:50 -0400 Received: by mail-ot0-f194.google.com with SMTP id i1so789896ota.3; Fri, 24 Mar 2017 09:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ETJ3HLaqFhYtI7JpMzCTfNjTqBvPYO+pNVyqtRZMCW8=; b=bJc32lkA+UUi8qCXdqk5oyKJq7/nD2UvBK472g/1fS25pjwWDDFfbWoGw8HvvNyuHB EwdbF57aOh4R+yptbC8XgBlGoWigz5i52rt1+gpLbNBxGp2uNNhdJFx/jMm7bqg6C/TN cpWEkaPHdDBVgb6gQWgNu//O2IS7tn9Ft0q594pYBZ/ssVCnNOeKAkT0odXz6qzvE8CT miR+BpOacc6PtWqu5/ij8yO9F3f/PaAYmkCXTHJf/0J2KAj1nlXK8y68X9DruSW7jJed 42OW0xIgd9yOauBi9xHXnzAuQN5X3xxg2uG7V/aFG4q+uBvP/QyfcKmiZ75pAgjQ8GgM ZL7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ETJ3HLaqFhYtI7JpMzCTfNjTqBvPYO+pNVyqtRZMCW8=; b=H50yi5bT44yX79VQ2nYLDUsYi90KI7zVyLIPxWPadSteXU0yzzw1NSS2mel9/ZHegB vNo14FLE3jWiRlHZgEasOYbxJ+1wwq2HlSIGcTQW2mUQK1W2Qg9iRXyXg5wtEZB/E5jj 5RGvFlRprW6DnC2yISDHjTpyc+rTTxzp6/zvdtm9EPO6ED0q4zangZQYtQJEdujX7WWU O7UcLWiVYdNkI3CQymUlyQNWZNhxEPpstWWo3X3kT5X40Kuh0FiazXl4Wn23n7BTCkuA 0BHA4+ES8+XmrTiQCgsqfFXsImT2FnBKfd4EbCekOg84NAgptruEanphMWtEFzssW15m 3I5A== X-Gm-Message-State: AFeK/H1qUPBvMDet1TWvHjNy4yEaQeQQQFgUBUm6sGxvF7p80QFa621xKDoFFWXI3E3CTeO+8DsIkZnbalhPyA== X-Received: by 10.157.37.162 with SMTP id q31mr4162262ota.255.1490372203550; Fri, 24 Mar 2017 09:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.5.145 with HTTP; Fri, 24 Mar 2017 09:16:43 -0700 (PDT) In-Reply-To: References: <4281f8e01b9fc5628cbf4a5c77abd642801e23c7.1490188942.git.dwmw2@infradead.org> From: Arnd Bergmann Date: Fri, 24 Mar 2017 17:16:43 +0100 X-Google-Sender-Auth: WHOp32BWE4LplH2NXy7F8R3CUbI Message-ID: Subject: Re: [PATCH 17/17] arm64: Do not expose PCI mmap through procfs To: David Woodhouse Cc: linux-pci , linux-arch , Linux Kernel Mailing List Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Fri, Mar 24, 2017 at 5:13 PM, Arnd Bergmann wrote: > On Wed, Mar 22, 2017 at 2:25 PM, David Woodhouse wrote: >> From: David Woodhouse >> >> Signed-off-by: David Woodhouse >> --- >> drivers/pci/proc.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c >> index 2d9cfa4..a940f4b 100644 >> --- a/drivers/pci/proc.c >> +++ b/drivers/pci/proc.c >> @@ -17,6 +17,11 @@ >> >> static int proc_initialized; /* = 0 */ >> >> +#ifdef __aarch64__ >> +/* ARM64 wants to be special and not expose this through /proc like everyone else */ >> +#undef HAVE_PCI_MMAP >> +#endif > > I'd still prefer this to be a whitelist of the existing architectures using PCI > MMAP in procfs, there is really no reason for arm64 to be special, the > one thing we want to control here is whether new architectures (including > arm64) that have never had either the sysfs or the procfs interface > should get one or both of them. > > As it seems that there are important use cases for the sysfs interface > and your patch series will just make that work everywhere, I'd argue > that we should just always provide the sysfs interface now, and use > HAVE_PCI_MMAP only control the procfs interface. > > That way, we turn on the sysfs interface on arc, arm64, frv and tile > as well as any future architecture with PCI support, but leave > the procfs support as opt-in. Something alone these lines, to replace your patch 17/17 and the one that turns on HAVE_PCI_MMAP for arm64. Signed-off-by: Arnd Bergmann diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 25d010d449a3..c517f1b724e0 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -980,8 +980,6 @@ void pci_remove_legacy_files(struct pci_bus *b) } #endif /* HAVE_PCI_LEGACY */ -#ifdef HAVE_PCI_MMAP - int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma, enum pci_mmap_api mmap_api) { @@ -1217,10 +1215,6 @@ static int pci_create_resource_files(struct pci_dev *pdev) } return 0; } -#else /* !HAVE_PCI_MMAP */ -int __weak pci_create_resource_files(struct pci_dev *dev) { return 0; } -void __weak pci_remove_resource_files(struct pci_dev *dev) { return; } -#endif /* HAVE_PCI_MMAP */ /** * pci_write_rom - used to enable access to the PCI ROM display diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 8dd38e69d6f2..6c2a15d4ebf9 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -21,14 +21,12 @@ void pci_create_firmware_label_files(struct pci_dev *pdev); void pci_remove_firmware_label_files(struct pci_dev *pdev); #endif void pci_cleanup_rom(struct pci_dev *dev); -#ifdef HAVE_PCI_MMAP enum pci_mmap_api { PCI_MMAP_SYSFS, /* mmap on /sys/bus/pci/devices//resource */ PCI_MMAP_PROCFS /* mmap on /proc/bus/pci/ */ }; int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vmai, enum pci_mmap_api mmap_api); -#endif int pci_probe_reset_function(struct pci_dev *dev); /**