lkml.org 
[lkml]   [2018]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] sparc: Use generic pci_mmap_resource_range()
From
Date
On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> Date: Mon, 19 Feb 2018 13:04:12 +0000
>
> >
> > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for
> > ARM64") added this generic function with the intent of using it
> > everywhere and ultimately killing the old arch-specific implementations.
> >
> > Let's get on with that eradication...
> >
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>
> David, the generic code is definitely doing different things.


Note that this is new "generic" code that I added last year, specifically to be able to obsolete all the old arch-specific code.
The main reason for the change was to take host physical addresses, instead of converting to via legacy "pci_resource_to_user()" even for the new sysfs API.

The details are hazy right now — I deliberately held back the "fun" architectures and sent only the no-brainers in the first batch via Bjorn's PCI tree, and then promptly forgot about it for a year.

But I definitely *attempted* to ensure that the new code would cover all the requirements of SPARC and the various architectures that have lifted and modified the SPARC PCI code over the years.

> For one, the sparc specific code allows mmap'ing any address range
> within a PCI bus device.  The generic code does not allow that.


You mean any address range in a given PCI bus even if there is no
actual device with a BAR at the corresponding address?

Would I be right to assume this was only available through the legacy
procfs API? I think it should be possible to accommodate it, and it
does look like I'd missed this requirement the first time round; thanks
for pointing it out.[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2018-02-19 16:24    [W:0.090 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site