From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Russell King <linux@arm.linux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Michal Simek <monstr@monstr.eu>,
Martin Wilck <martin.wilck@ts.fujitsu.com>,
Linux PCI <linux-pci@vger.kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH RFC v2 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap
Date: Wed, 12 Nov 2014 10:27:26 +0000 [thread overview]
Message-ID: <20141112102726.GD6759@red-moon> (raw)
In-Reply-To: <1415777029.5124.42.camel@kernel.crashing.org>
On Wed, Nov 12, 2014 at 07:23:49AM +0000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-11-10 at 16:04 -0700, Bjorn Helgaas wrote:
> > 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().
> >
> > 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?
> >
> > FWIW, I think the discussion leading up to pci_resource_to_user() is
> > here:
> > http://lkml.iu.edu/hypermail/linux/kernel/0504.3/0467.html
>
> Oh, man... I remember that was all a giant trainwreck and some stuff
> just couldn't be made completely right due to broken assumptions by
> the proc code and users of it... but I don't remember all the details.
>
> I think /proc users don't necessarily pass a BAR value but something
> they try to somewhat translates themselves via the "resources" file,
> which ends up working ... or not, depending on various factors such
> as 32 vs 64 bit etc...
>
> I wonder who still uses this interface....
+1, even though I do not think that leaving it as it is is a good idea,
hence I posted this series.
I tried to fix it while fixing the way ARM pcibios code handles
pci_mmap_page_range() (for both procfs and sysfs mappings).
I will do what Bjorn suggested, more comments from arches maintainers
are welcome.
Lorenzo
next prev parent reply other threads:[~2014-11-12 10:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 16:28 [PATCH RFC v2 0/2] Fix procfs PCI resources mmap Lorenzo Pieralisi
2014-10-24 16:28 ` [PATCH RFC v2 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap Lorenzo Pieralisi
2014-11-10 23:04 ` Bjorn Helgaas
2014-11-11 11:48 ` Lorenzo Pieralisi
2014-11-11 14:20 ` Bjorn Helgaas
2014-11-11 15:57 ` Lorenzo Pieralisi
2014-11-11 17:19 ` Bjorn Helgaas
2014-11-13 11:32 ` Lorenzo Pieralisi
2014-11-12 7:23 ` Benjamin Herrenschmidt
2014-11-12 10:27 ` Lorenzo Pieralisi [this message]
2014-10-24 16:28 ` [PATCH RFC v2 2/2] arm: kernel: fix pci_mmap_page_range() offset calculation Lorenzo Pieralisi
2014-11-04 14:15 ` [PATCH RFC v2 0/2] Fix procfs PCI resources mmap Lorenzo Pieralisi
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=20141112102726.GD6759@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=martin.wilck@ts.fujitsu.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
/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).