From: Will Deacon <will.deacon@arm.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 17/17] arm64: Do not expose PCI mmap through procfs
Date: Wed, 22 Mar 2017 14:18:21 +0000 [thread overview]
Message-ID: <20170322141820.GI8026@arm.com> (raw)
In-Reply-To: <5362b452-8526-1a97-ebf7-7052f1af56f7@codeaurora.org>
On Wed, Mar 22, 2017 at 10:15:04AM -0400, Sinan Kaya wrote:
> On 3/22/2017 10:04 AM, David Woodhouse wrote:
> > On Wed, 2017-03-22 at 09:54 -0400, Sinan Kaya wrote:
> >> On 3/22/2017 9:25 AM, David Woodhouse wrote:
> >>>
> >>>
> >>> +#ifdef __aarch64__
> >>> +/* ARM64 wants to be special and not expose this through /proc
> >>> like everyone else */
> >>> +#undef HAVE_PCI_MMAP
> >>> +#endif
> >>> +
> >> Where is this ARM64 special requirement coming from?
> >
> > The idea is that as a new platform, ARM64 shouldn't need to implement
> > legacy userspace interfaces.
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422571.html
> >
>
> Aren't we breaking an ABI for userspace? I know DPDK relies on this feature.
It relies on the /proc interface? That's the first I've ever heard of that
-- everybody so far has only been interested in the sysfs stuff.
Nothing's more broken than before, because we've never supported the /proc
interface, but if existing arm64 code out there is failing because of that
then I'm of course open to supporting it. I'm just surprised that nobody
else has come up with that before, since DPDK is in common use.
Can you point me at the specific code, please?
Will
next prev parent reply other threads:[~2017-03-22 14:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 13:25 [PATCH 00/17] PCI resource mmap cleanup David Woodhouse
2017-03-22 13:25 ` [PATCH 01/17] pci: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms David Woodhouse
2017-03-22 13:25 ` [PATCH 02/17] pci: Fix another sanity check bug in /proc/pci mmap David Woodhouse
2017-03-22 13:25 ` [PATCH 03/17] pci: Only allow WC mmap on prefetchable resources David Woodhouse
2017-03-24 16:05 ` Arnd Bergmann
2017-03-24 17:04 ` David Woodhouse
2017-03-22 13:25 ` [PATCH 04/17] pci: Add arch_can_pci_mmap_wc() macro David Woodhouse
2017-04-04 21:36 ` Bjorn Helgaas
2017-04-05 7:22 ` David Woodhouse
2017-03-22 13:25 ` [PATCH 05/17] pci: Move multiple declarations of pci_mmap_page_range() to <linux/pci.h> David Woodhouse
2017-03-22 13:25 ` [PATCH 06/17] pci: Add HAVE_PCI_MMAP_IO to architectures which can mmap() I/O space David Woodhouse
2017-03-22 13:25 ` [PATCH 07/17] pci: Use BAR index in sysfs attr->private instead of resource pointer David Woodhouse
2017-03-22 13:25 ` [PATCH 08/17] pci: Add BAR index argument to pci_mmap_page_range() David Woodhouse
2017-03-22 13:25 ` [PATCH 09/17] pci: Add pci_mmap_resource_range() and use it for ARM64 David Woodhouse
2017-03-22 13:25 ` [PATCH 10/17] arm: Use generic pci_mmap_resource_range() David Woodhouse
2017-03-22 13:25 ` [PATCH 11/17] cris: " David Woodhouse
2017-03-22 13:33 ` Jesper Nilsson
2017-03-22 13:25 ` [PATCH 12/17] mips: " David Woodhouse
2017-03-22 13:25 ` [PATCH 13/17] mn10300: " David Woodhouse
2017-03-22 13:25 ` [PATCH 14/17] parisc: " David Woodhouse
2017-03-22 13:25 ` [PATCH 15/17] sh: " David Woodhouse
2017-03-22 13:25 ` [PATCH 16/17] unicore: " David Woodhouse
2017-03-22 13:25 ` [PATCH 17/17] arm64: Do not expose PCI mmap through procfs David Woodhouse
2017-03-22 13:54 ` Sinan Kaya
2017-03-22 14:04 ` David Woodhouse
2017-03-22 14:15 ` Sinan Kaya
2017-03-22 14:18 ` Will Deacon [this message]
2017-03-22 15:40 ` Sinan Kaya
2017-03-24 16:13 ` Arnd Bergmann
2017-03-24 16:16 ` Arnd Bergmann
2017-03-24 16:23 ` David Woodhouse
2017-03-24 16:20 ` David Woodhouse
2017-03-23 14:29 ` [PATCH 18/17] x86: Use generic pci_mmap_resource_range() David Woodhouse
2017-03-24 11:40 ` [PATCH 00/17] PCI resource mmap cleanup David Woodhouse
2017-03-24 16:57 ` Luck, Tony
2017-03-24 16:20 ` Arnd Bergmann
2017-04-04 22:43 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170322141820.GI8026@arm.com \
--to=will.deacon@arm.com \
--cc=dwmw2@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).