Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbaKKOU4 (ORCPT ); Tue, 11 Nov 2014 09:20:56 -0500 Received: from mail-qa0-f41.google.com ([209.85.216.41]:64861 "EHLO mail-qa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751984AbaKKOUx (ORCPT ); Tue, 11 Nov 2014 09:20:53 -0500 MIME-Version: 1.0 In-Reply-To: <20141111114825.GA4135@red-moon> References: <1414168089-8130-1-git-send-email-lorenzo.pieralisi@arm.com> <1414168089-8130-2-git-send-email-lorenzo.pieralisi@arm.com> <20141110230454.GA21470@google.com> <20141111114825.GA4135@red-moon> From: Bjorn Helgaas Date: Tue, 11 Nov 2014 07:20:31 -0700 Message-ID: Subject: Re: [PATCH RFC v2 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap To: Lorenzo Pieralisi Cc: "linux-kernel@vger.kernel.org" , Arnd Bergmann , Benjamin Herrenschmidt , Russell King , "David S. Miller" , Michal Simek , Martin Wilck , Linux PCI , Michael Ellerman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 11, 2014 at 4:48 AM, Lorenzo Pieralisi wrote: > On Mon, Nov 10, 2014 at 11:04:54PM +0000, Bjorn Helgaas wrote: >> ... >> Here's what I think I understand so far: >> >> Applications can mmap PCI memory space via either sysfs or procfs (the >> procfs method is deprecated but still supported): >> >> - In sysfs, there's a separate /sys/devices/pci*/.../resource* file >> for each device BAR, and the application opens the appropriate >> file and supplies the offset from the beginning of the BAR as the >> mmap(2) offset. >> >> - In procfs, the application opens the single /proc/bus/pci/... file >> for the device. On most platforms, it supplies the CPU physical >> address as the mmap(2) offset. On a few platforms, such as SPARC, >> it supplies the bus address, i.e., a BAR value, instead. >> >> But I'm not sure I have this right. If the procfs offset is either the >> CPU physical address or the BAR value, then pci_resource_to_user() >> should be (depending on the arch) either a no-op or use >> pci_resource_to_bus(). > > Exactly (pcibios_resource_to_bus() ?). > >> But that's not how it's implemented. Maybe it *could* be? If >> pci_resource_to_user() gives you something that's not a CPU physical >> address and not a bus address, what *does* it give you, and why would we >> need this third kind of thing? > > Well, you need a per arch function implementation where to define if > the conversion from CPU physical address to PCI bus should take place > or not right ? As you mentioned above, if that should be a per-arch > decision, there has to be a per-arch function to filter the resource > in question, I guess that's my understanding behind pci_resource_to_user(), > but I am not sure either, and understanding that was the primary reason > for this patchset so comments are welcome. I agree that we need pci_resource_to_user() because arches do different things, so we can't just remove pci_resource_to_user() and replace it with pci_resource_to_bus(). My point is that we have a generic pci_resource_to_user() implementation that does nothing, and if an arch *does* implement its own pci_resource_to_user(), it seems like it should simply call pci_resource_to_user(). Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/