From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>,
Liviu Dudau <Liviu.Dudau@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: pci_ioremap_set_mem_type(), pci_remap_iospace()
Date: Thu, 28 Apr 2016 16:38:49 +0200 [thread overview]
Message-ID: <20160428163849.2fb5607b@free-electrons.com> (raw)
In-Reply-To: <20160428143332.GC12470@localhost>
Hello,
On Thu, 28 Apr 2016 09:33:32 -0500, Bjorn Helgaas wrote:
> [+cc linux-pci, manually inserted reply, sorry again]
>
> Liviu wrote:
> > On Wed, Apr 27, 2016 at 05:58:27PM -0500, Bjorn Helgaas wrote:
> >> Looking at __arm_ioremap_pfn_caller() makes me
> >> suspect that pci_remap_iospace() is not safe on arm.
>
> > Hmm, not sure how you reached that conclusion. __arm_ioremap_pfn_caller()
> > does call in the end ioremap_page_range() for ARMv7 || ARM_LPAE, which is
> > what pci_remap_iospace() does as well. Beside the possibly different
> > pgprot_t values, what would make it unsafe for arm?
>
> The different pgprot_t is exactly what I'm worried about. The callers of
> pci_ioremap_io() probably get the right thing (a pgprot tweaked to deal
> with this Cortex problem), but other callers of ioremap_page_range(),
> pci_remap_iospace() in particular, don't get that tweak:
>
> pci_ioremap_io
> ioremap_page_range(..., __pgprot(get_mem_type(pci_ioremap_mem_type)->prot_pte))
>
> pci_remap_iospace
> ioremap_page_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pud_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pmd_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pte_range(..., pgprot_device(PAGE_KERNEL))
> set_pte_at(..., pfn_pte(pfn, pgprot_device(PAGE_KERNEL)))
Indeed. Which is why we should get rid of one of the two interfaces.
Since pci_remap_iospace() is the generic one, I guess that's the one we
should migrate to.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
_______________________________________________
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: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: pci_ioremap_set_mem_type(), pci_remap_iospace()
Date: Thu, 28 Apr 2016 16:38:49 +0200 [thread overview]
Message-ID: <20160428163849.2fb5607b@free-electrons.com> (raw)
In-Reply-To: <20160428143332.GC12470@localhost>
Hello,
On Thu, 28 Apr 2016 09:33:32 -0500, Bjorn Helgaas wrote:
> [+cc linux-pci, manually inserted reply, sorry again]
>
> Liviu wrote:
> > On Wed, Apr 27, 2016 at 05:58:27PM -0500, Bjorn Helgaas wrote:
> >> Looking at __arm_ioremap_pfn_caller() makes me
> >> suspect that pci_remap_iospace() is not safe on arm.
>
> > Hmm, not sure how you reached that conclusion. __arm_ioremap_pfn_caller()
> > does call in the end ioremap_page_range() for ARMv7 || ARM_LPAE, which is
> > what pci_remap_iospace() does as well. Beside the possibly different
> > pgprot_t values, what would make it unsafe for arm?
>
> The different pgprot_t is exactly what I'm worried about. The callers of
> pci_ioremap_io() probably get the right thing (a pgprot tweaked to deal
> with this Cortex problem), but other callers of ioremap_page_range(),
> pci_remap_iospace() in particular, don't get that tweak:
>
> pci_ioremap_io
> ioremap_page_range(..., __pgprot(get_mem_type(pci_ioremap_mem_type)->prot_pte))
>
> pci_remap_iospace
> ioremap_page_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pud_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pmd_range(..., pgprot_device(PAGE_KERNEL))
> ioremap_pte_range(..., pgprot_device(PAGE_KERNEL))
> set_pte_at(..., pfn_pte(pfn, pgprot_device(PAGE_KERNEL)))
Indeed. Which is why we should get rid of one of the two interfaces.
Since pci_remap_iospace() is the generic one, I guess that's the one we
should migrate to.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-04-28 14:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 22:58 pci_ioremap_set_mem_type(), pci_remap_iospace() Bjorn Helgaas
2016-04-28 7:21 ` Thomas Petazzoni
2016-04-28 12:06 ` Liviu Dudau
2016-04-28 12:13 ` Thomas Petazzoni
2016-04-28 13:02 ` Liviu Dudau
2016-04-28 13:12 ` Thomas Petazzoni
2016-04-28 14:41 ` Liviu Dudau
2016-04-28 14:47 ` Thomas Petazzoni
2016-04-28 16:23 ` Arnd Bergmann
2016-04-28 14:19 ` Bjorn Helgaas
2016-04-28 14:19 ` Bjorn Helgaas
2016-04-28 14:36 ` Thomas Petazzoni
2016-04-28 14:36 ` Thomas Petazzoni
2016-04-28 16:03 ` Bjorn Helgaas
2016-04-28 16:03 ` Bjorn Helgaas
2016-04-28 14:33 ` Bjorn Helgaas
2016-04-28 14:33 ` Bjorn Helgaas
2016-04-28 14:38 ` Thomas Petazzoni [this message]
2016-04-28 14:38 ` Thomas Petazzoni
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=20160428163849.2fb5607b@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=Liviu.Dudau@arm.com \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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.