From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
Date: Fri, 10 Oct 2014 14:58:04 +0100 [thread overview]
Message-ID: <20141010135804.GA26646@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <1831157.eN0OxS7i7m@wuerfel>
On Thu, Oct 09, 2014 at 11:51:43AM +0100, Arnd Bergmann wrote:
[...]
> > 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.
>
> My best guess is that this is a typo and that Darrick meant PCI_MMAP_SYSFS
> in the changelog, which is the same thing that the code does. It's also
> the sensible thing to do.
>
> This probably means that the procfs interface is now also broken on
> sparc.
>
> > I will try to grab an integrator board to give it a go.
>
> Ok, good idea.
Grabbed, tested it, my theory was correct, I can't map PCI resources
to userspace. Actually, if I pass resource offset as a fixed-up address, mmap
succeeds through proc, but it does not mmap the resource, it maps
the resource + mem_offset that happens to be RAM :D for the PCI slot I am
using.
I am testing on an oldish (3.16) kernel since I am having trouble with
mainline PCI and my network adapter on integrator, but I do not see why this
is a problem, this bug has been there forever.
By removing mem_offset from pci_mmap_page_range() everything works fine,
both proc and sys mappings are ok.
> > > > 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.
>
> The PCI core tries to be ready for PCI host bridges that have multiple
> discontiguous memory spaces with different offsets, although I don't know
> of anybody has that. However if we decide to implement a generic
> pci_mmap_page_range that tries to take the offset into account, we should
> use the resource list in the host bridge because it can tell us the correct
> offsets.
>
> However, given what you found, the procfs interface being broken since
> 2010 on both architectures (arm32 and sparc) that try to honor the offset,
> we should probably go back to your previous suggestion of removing
> the offset handling, which would make it possible to use the procfs
> interface and the sysfs interface on all architectures.
>
> Would you be able to prepare a patch that does this and circulate that
> with the sparc, powerpc and microblaze maintainers as well as Darrick
> and Martin who were involved with the pci_mmap_fits change?
Yes, but let's step back a second. I think that the proc interface
should expect an offset as passed to the user in /proc/bus/pci/devices,
and there the resource is exposed through pci_resource_to_user().
Hence, the pci_mmap_fits() should check the offset against the
resource filtered through pci_resource_to_user(), job done, patch
is trivial, and does what pci_resource_to_user() was meant for IMHO.
Then we have to decide what to do with arm32 code:
1) we remove mem_offset from pci_mmap_page_range() (and rely on default
pci_resource_to_user())
or
2) we provide pci_resource_to_user() for arm32 which does the CPU->bus
conversion for us (and leave mem_offset as-is in pci_mmap_range())
Thoughts ?
Thanks,
Lorenzo
next prev parent reply other threads:[~2014-10-10 13:58 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 at amd.com
2014-09-28 20:53 ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit at amd.com
2014-10-10 13:45 ` Mark Rutland
2014-10-24 12:08 ` Suravee Suthikulpanit
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit at amd.com
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
2014-10-09 10:51 ` Arnd Bergmann
2014-10-10 13:58 ` Lorenzo Pieralisi [this message]
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
2014-11-06 0:06 ` Arnd Bergmann
2014-12-29 19:32 ` Suravee Suthikulpanit
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 at amd.com
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
2014-09-28 20:53 ` [RFC 4/4] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit at amd.com
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=20141010135804.GA26646@e102568-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=linux-arm-kernel@lists.infradead.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).