All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	lorenzo.pieralisi@arm.com, Arnd Bergmann <arnd@arndb.de>,
	david.daney@cavium.com, catalin.marinas@arm.com,
	Liviu.Dudau@arm.com, rrichter@cavium.com, hanjun.guo@linaro.org,
	linux-pci <linux-pci@vger.kernel.org>,
	bhelgaas@google.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm64: pci: add support for pci_mmap_page_range
Date: Mon, 20 Mar 2017 14:07:38 +0000	[thread overview]
Message-ID: <1490018858.5036.19.camel@infradead.org> (raw)
In-Reply-To: <20170320131836.GM17263@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]

On Mon, 2017-03-20 at 13:18 +0000, Will Deacon wrote:
> > The thing is, this *isn't* an architecture-specific interface where you
> > get a clean slate. It's a cross-platform interface. Legacy and horrid,
> > sure. But it does you no harm.

> I don't agree with that: it provides (privileged) userspace with a way to
> map non-prefetchable BARs using write-combining memory attributes, which
> could lead to mismatched memory attributes against a kernel mapping of the
> same BAR and is something that you can't achieve using the sysfs API.

I think that's just a bug. I'll add it to my list. We shouldn't be
allowing a WC mapping on a non-prefetchable resource, should we?

For that matter, I think it allows you mmap a range of MMIO addresses
that correspond to an I/O BAR, and on platforms which allow
pci_mmap_io, the converse. That seems... suboptimal.
 
> > What *else* don't you like having in /proc? Shall we have a clean slate
> > and eliminate *everything* other than actual processes from /proc for
> > the next architecture we add to the tree? If not, why not?
> It's not about what we like and don't like in /proc, it's about not
> promoting legacy that we don't need. If somebody actually needs the /proc
> interface, fine, we can support it. But all the people asking for this have
> been concerned solely about the sysfs interface, so I'd just like the two
> divorced from each other so that we can provide what people are asking for
> without pulling in a deprecated interface at the same time.
> 
> This should be straightforward.

Sure, but fairly much orthogonal. I'll roll it in. It's fairly much in
the noise now I'm this far down the rabbithole...

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: dwmw2@infradead.org (David Woodhouse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm64: pci: add support for pci_mmap_page_range
Date: Mon, 20 Mar 2017 14:07:38 +0000	[thread overview]
Message-ID: <1490018858.5036.19.camel@infradead.org> (raw)
In-Reply-To: <20170320131836.GM17263@arm.com>

On Mon, 2017-03-20 at 13:18 +0000, Will Deacon wrote:
> > The thing is, this *isn't* an architecture-specific interface where you
> > get a clean slate. It's a cross-platform interface. Legacy and horrid,
> > sure. But it does you no harm.

> I don't agree with that: it provides (privileged) userspace with a way to
> map non-prefetchable BARs using write-combining memory attributes, which
> could lead to mismatched memory attributes against a kernel mapping of the
> same BAR and is something that you can't achieve using the sysfs API.

I think that's just a bug. I'll add it to my list. We shouldn't be
allowing a WC mapping on a non-prefetchable resource, should we?

For that matter, I think it allows you mmap a range of MMIO addresses
that correspond to an I/O BAR, and on platforms which allow
pci_mmap_io, the converse. That seems... suboptimal.
?
> > What *else* don't you like having in /proc? Shall we have a clean slate
> > and eliminate *everything* other than actual processes from /proc for
> > the next architecture we add to the tree? If not, why not?
> It's not about what we like and don't like in /proc, it's about not
> promoting legacy that we don't need. If somebody actually needs the /proc
> interface, fine, we can support it. But all the people asking for this have
> been concerned solely about the sysfs interface, so I'd just like the two
> divorced from each other so that we can provide what people are asking for
> without pulling in a deprecated interface at the same time.
> 
> This should be straightforward.

Sure, but fairly much orthogonal. I'll roll it in. It's fairly much in
the noise now I'm this far down the rabbithole...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170320/fb220219/attachment.bin>

  reply	other threads:[~2017-03-20 14:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 21:10 [PATCH v2] arm64: pci: add support for pci_mmap_page_range Jerin Jacob
2016-04-15 13:09 ` Will Deacon
2016-04-15 18:45   ` Arnd Bergmann
2016-04-18 14:01     ` Jerin Jacob
2016-04-18 14:15       ` Arnd Bergmann
2016-04-18 14:53         ` Jerin Jacob
2016-04-18 15:00           ` Arnd Bergmann
2016-04-18 15:21             ` Jerin Jacob
2016-04-18 15:31               ` Arnd Bergmann
2016-04-18 15:40                 ` Will Deacon
2016-04-18 17:45                   ` Jerin Jacob
2016-04-18 17:46                     ` Arnd Bergmann
2017-03-15 21:01                 ` David Woodhouse
2017-03-20 13:18                   ` Will Deacon
2017-03-20 14:07                     ` David Woodhouse [this message]
2017-03-20 14:07                       ` David Woodhouse
2016-04-18 13:43   ` Jerin Jacob
2017-03-16 12:17   ` David Woodhouse
2017-03-16 12:17     ` David Woodhouse
2017-03-20 13:21     ` Will Deacon
2017-03-20 13:21       ` Will Deacon

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=1490018858.5036.19.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.daney@cavium.com \
    --cc=hanjun.guo@linaro.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rrichter@cavium.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.