Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

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.

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