devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"rmk+kernel@arm.linux.org.uk" <rmk+kernel@arm.linux.org.uk>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
Date: Thu, 9 Oct 2014 10:04:20 +0100	[thread overview]
Message-ID: <20141009090420.GA16293@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <2323270.n17xqW47JB@wuerfel>

On Wed, Oct 08, 2014 at 03:47:43PM +0100, Arnd Bergmann wrote:
> On Wednesday 08 October 2014 11:19:43 Lorenzo Pieralisi wrote:
> > 
> > Ok. So, unless I am missing something, on platform with mem_offset != 0
> > /proc and /sys interfaces for remapping PCI resources can't work (IIUC
> > the proc interface expects the user to pass in the resource address as
> > seen from /proc/bus/pci/devices - which are not BAR values. Even if the
> > user passed the BAR value to mmap, pci_mmap_fits() in proc_bus_pci_mmap()
> > would fail since it compares the pgoff to resource values, which are not
> > BAR values).
> 
> I think you are right for the sysfs interface, that one can't possibly
> work because of the incorrect address computation.
> 
> For the /procfs interface, I think it can work as long as the offsets
> used there are coming from the config space dump in /proc/bus/pci/*
> rather than from the /sys/bus/pci/devices/*/resource file.
>  
> > As things stand I think we can safely remove the mem_offset (and
> > pci_sys_data dependency) from pci_mmap_page_range(). I do not think
> > we can break userspace in any way, basically because it can't work at
> > the moment, again, happy to be corrected if I am wrong, please shout.
> 
> Please look at the procfs interface again. That one can be defined
> in two ways (either like sparc and arm, or like powerpc and microblaze)
> but either one should be able to work with user space that expects
> that interface and break with user space that expects the other one.

I agree as long as pci_mmap_page_range() is concerned, but I am
referring to the pci_mmap_fits() implementation here:

	start = vma->vm_pgoff;
	size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
	pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
			pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
	if (start >= pci_start && start < pci_start + size &&
			start + nr <= pci_start + size)
		return 1;
	return 0;

pci_mmap_fits(), when mapping from procfs always check the offset against
resources, which are fixed-up addresses. If we passed the values dumped
from the device config space (as pci_mmap_page_range() expects on arm) IMHO
the check above would fail (always referring to platforms where
mem_offset != 0).

Last changes where introduced by commit 8c05cd08a, whose commit log adds
to my confusion:

"[...] I think what we want here is for pci_start to be 0 when mmap_api ==
PCI_MMAP_PROCFS.[...]"

But that's not what the code does.

I will try to grab an integrator board to give it a go.

> > Or we can add mem_offset to the host bridge (after all architectures like
> > PowerPC and Microblaze have a pci_mem_offset variable in their host
> > controllers), but still, this removes pci_sys_data dependency but does
> > not solve the pci_mmap_page_range() issue.
> 
> The host bridge already stores the mem_offset in terms of the resource
> list, so we could readily use that, except that it might break the
> powerpc hack if that is still in use.

Well, yes, I am not saying it can't be done by using the resources list,
I am just trying to understand if that's really useful.

Thank you !
Lorenzo


  reply	other threads:[~2014-10-09  9:04 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 20:53 [RFC 0/4] Add PCI/MSI(x) support for AMD Seattle Platform suravee.suthikulpanit
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit
2014-09-29 14:36   ` Arnd Bergmann
2014-09-30 12:03     ` Lorenzo Pieralisi
2014-09-30 12:31       ` Arnd Bergmann
2014-09-30 16:12         ` Lorenzo Pieralisi
2014-09-30 16:42           ` Liviu Dudau
2014-09-30 17:35             ` Lorenzo Pieralisi
2014-09-30 17:48               ` Liviu Dudau
2014-09-30 18:54                 ` Arnd Bergmann
2014-09-30 20:01                   ` Arnd Bergmann
2014-10-01  8:46                     ` Liviu Dudau
2014-10-01  9:38                       ` Arnd Bergmann
2014-10-07 12:06                         ` Lorenzo Pieralisi
2014-10-07 13:52                           ` Arnd Bergmann
2014-10-07 14:47                             ` Lorenzo Pieralisi
2014-10-07 21:39                               ` Arnd Bergmann
2014-10-08 10:19                                 ` Lorenzo Pieralisi
2014-10-08 14:47                                   ` Arnd Bergmann
2014-10-09  9:04                                     ` Lorenzo Pieralisi [this message]
2014-10-09 10:51                                       ` Arnd Bergmann
2014-10-10 13:58                                         ` Lorenzo Pieralisi
2014-10-10 18:31                                           ` Arnd Bergmann
2014-10-13  9:36                                             ` Lorenzo Pieralisi
2014-10-22 15:59                         ` Lorenzo Pieralisi
2014-10-22 16:49                           ` Bjorn Helgaas
2014-10-22 20:52                           ` Arnd Bergmann
2014-10-23  9:13                             ` Liviu Dudau
2014-10-23 11:27                               ` Lorenzo Pieralisi
2014-10-23 16:52                                 ` Jason Gunthorpe
2014-10-27 16:10                                   ` Lorenzo Pieralisi
2014-10-23 13:33                               ` Arnd Bergmann
2014-10-24 10:04                                 ` Liviu Dudau
2014-11-05 23:40                                 ` Bjorn Helgaas
     [not found]                                   ` <20141105234058.GK6168-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2014-11-06  0:06                                     ` Arnd Bergmann
2014-12-29 19:32                                 ` Suravee Suthikulpanit
     [not found]                                   ` <54A1AC5C.7000903-5C7GfCeVMHo@public.gmane.org>
2015-01-02 11:55                                     ` Lorenzo Pieralisi
2015-01-02 18:18                                       ` Suravee Suthikulanit
2015-01-02 21:09                                         ` Arnd Bergmann
2015-01-05 14:48                                           ` Lorenzo Pieralisi
2014-11-05 23:39                             ` Bjorn Helgaas
2014-11-06  0:05                               ` Arnd Bergmann
2014-11-06  9:52                                 ` Lorenzo Pieralisi
2014-09-29 19:19   ` Sunil Kovvuri
2014-09-28 20:53 ` [RFC 3/4] arm64: Do not call enable PCI resources when specify PCI_PROBE_ONLY suravee.suthikulpanit
2014-09-29 14:38   ` Arnd Bergmann
2014-09-29 18:17   ` Bjorn Helgaas
2015-06-23 22:34     ` Benjamin Herrenschmidt
2015-06-23 23:05       ` Russell King - ARM Linux
2015-06-23 22:32   ` Benjamin Herrenschmidt
     [not found] ` <1411937610-22125-1-git-send-email-suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org>
2014-09-28 20:53   ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit-5C7GfCeVMHo
2014-10-10 13:45     ` Mark Rutland
2014-10-24 12:08       ` Suravee Suthikulpanit
2014-09-28 20:53   ` [RFC 4/4] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit-5C7GfCeVMHo
2014-09-28 21:35     ` Suravee Suthikulpanit
2014-09-29 14:23       ` Thomas Gleixner
2014-09-29 14:42     ` Arnd Bergmann

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=20141009090420.GA16293@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    /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).