From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [QUESTION] Early Write Acknowledge for PCIe configuration space
Date: Thu, 9 Feb 2017 14:38:05 +0000 [thread overview]
Message-ID: <20170209143805.GA31693@red-moon> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1FA25E1C@lhreml507-mbx>
On Thu, Feb 09, 2017 at 11:42:18AM +0000, Gabriele Paoloni wrote:
[...]
> > > The ARMv8 ARM also says that the E attribute is a hint, so there's no
> > > guarantee that it's actually honoured by the implementation. However,
> > > now that it explicitly mentions PCI config space, the intention is
> > clearly
> > > that nE *is* honoured for systems using PCIe, so I agree that we
> > should make
> > > this change. I don't want to use the nE type for all ioremap
> > invocations,
> > > though.
> >
> > I suspect this is a potential issue on ARM 32-bit systems too(?).
> > Fixing
> > IO space should be reasonably simple, we just have to change the
> > pgprot_device() in pci_remap_iospace() to pgprot_noncached() (they are
> > the same attributes on ARM 32-bit already if I am not mistaken).
>
> Agreed on this. Actually I noticed that pci_remap_iospace() is __weak
> but no other definitions are present...
Yes I will remove it.
> > What do we want to do for config space ? Implement ioremap_uc() for
> > ARM/ARM64 (and add a devm_ioremap_uc() call to use it in basically all
> > drivers/pci/host implementations to map config space - or we just patch
> > the ioremap calls in drivers/pci/ecam.c and we assume the other hosts
> > controllers have purportedly called devm_ioremap() because on those
> > platforms it just works ok till further notice ?)
>
> Well if my understanding is correct we are 100% positive that this issue
> affects controllers mounted on ARM and ARM64, right?
> If this is correct I would look at drivers/pci/host/Kconfig and see which
> controllers depend on ARM or ARM64; for these controllers I would replace
> devm_ioremap() with devm_ioremap_uc().
> Obviously I would also replace the calls in drivers/pci/ecam.c...
>
> What do you think?
I share Will's concern on the _uc API, I will probably add a
pci_remap_cfgspace() API that would fall back to ioremap_nocache()
by default (ie if the arch does not override it).
Adding a devm_ioremap_* version seems overkill to me.
I will send a patch series, we will take it from there.
Cheers,
Lorenzo
next prev parent reply other threads:[~2017-02-09 14:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 11:15 [QUESTION] Early Write Acknowledge for PCIe configuration space John Garry
2017-01-06 11:24 ` Arnd Bergmann
2017-01-06 11:42 ` Will Deacon
2017-02-08 18:35 ` Lorenzo Pieralisi
2017-02-09 11:30 ` Will Deacon
2017-02-09 11:42 ` Gabriele Paoloni
2017-02-09 14:38 ` Lorenzo Pieralisi [this message]
2017-02-09 14:53 ` Gabriele Paoloni
2017-01-09 10:59 ` John Garry
2017-01-09 11:23 ` Will Deacon
2017-01-09 11:52 ` Arnd Bergmann
2017-01-10 10:22 ` John Garry
2017-01-10 10:47 ` Gabriele Paoloni
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=20170209143805.GA31693@red-moon \
--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 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.